-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add fakebinary for acommodating testing the child process management #371
Conversation
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for narrowing the scope and giving another stab. The end of the test looks good.
I have a more preferred approach to isolation of the incidental binary, ex so that it doesn't end up depending on anything but moreos. I also prefer to be more complete in how we launch processes as there are a couple key utilities used by envoy.Run. I made a more comprehensive sketch here, which will replace most of the code except the bottom of the test you wrote. https://github.com/tetratelabs/func-e/compare/fake-deux
Note: It took a while for me to figure out why things were moving around. While your description says the test case desired in text, and that's good, we should try to make notes either in the description about other structural change and why or self-PR comments. This helps explain the incidental change and why, in this case around needing to get a relative path to the module (the reason is that the fake source is different than fake envoy as it is importing a fully-qualified go import). When change is explained, it can help others understand the why vs have them guessing or figuring it out from scratch in a review out of timezone.
@codefromthecrypt do you want me to continue this or you to create a PR from your branch? Sorry, it is not clear since as you said: "I made a more comprehensive sketch here, which will replace most of the code except the bottom of the test you wrote." So I feel like I'll just copy-and-paste yours and add that tiny bit of change which I'm not sure why I want to do that 😅. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
main thing I meant was that retain almost all "moreos_linux_test.go" except the setup which is different per the other branch. Feel free to continue that branch and raise a PR out of it or force push this one and delete the other.
It would be nice to not increment notify watchers with new issue numbers as much as we have been, so I prefer to not raise yet another PR on the same topic. IOTW I prefer to rework this PR vs drop another PR and create another one on the same topic. That's why I didn't raise a PR on the other branch.
Signed-off-by: Dhi Aurrahman <dio@rockybars.com> Co-authored-by: Adrian Cole <adrian@tetrate.io>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
@codefromthecrypt when you have time, please take a look. Mostly I migrated everything you have done to this branch, so mostly you have seen all of these before 😅. |
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. some minor concerns when addressed, please merge!
A follow-up would be to matrix this test and show the behavior on TERM vs KILL. That can be a follow-up PR actually.
|
||
// TestProcessGroupAttr_Kill tests sending SIGKILL to fake func-e and makes sure fake envoy receives | ||
// SIGTERM (as defined in Pdeathsig). | ||
func TestProcessGroupAttr_Kill(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to use a condition on runtime.GOOS
vs _linux
because myself and others might refactor something and it will break compilation only on CI.
So, basically handle this in a t.Skip()
instead of build condition please? We can do this because there are no linux-specific code called here. When doing the skip, do note why it won't work in darwin or windows in case we can follow-up.
@mathetake if you have some other notes of interest, feel free to review also. Otherwise, with things already said LGTM! |
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
@@ -0,0 +1,73 @@ | |||
package main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit I would like to name this to fake_func_e.go
following the Go convention 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a mixed feeling about this since func-e
is a name. I will defer this to @codefromthecrypt 🙏🏽.
This is a follow-up for #371 (review) to test all possible signals to func-e. A minor change on checking the stderr: this uses scanner instead of peek on the buffer since for some reason redirecting cmd.Stderr to a buffer doesn't give complete stderr after the process is terminated. Hence here we use scanner to io.ReadCloser of cmd.StderrPipe() instead. Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
This is a follow-up for #371 (review) to test a set of possible signals (`SIGINT`, `SIGTERM`, `SIGKILL`) to terminate `func-e`. A minor change on checking the stderr: this PR uses a scanner instead of peeking on the buffer since for some reason redirecting `cmd.Stderr` to a buffer doesn't give complete stderr after the process is terminated. Hence here we use a scanner to `io.ReadCloser` returned by `cmd.StderrPipe()` instead. Signed-off-by: Dhi Aurrahman <dio@rockybars.com> Co-authored-by: Takeshi Yoneda <takeshi@tetrate.io>
This adds the
internal/test/fakebinary
package allowing us to test running a fakefunc-e
process that spawns a fakeenvoy
. This allows us to isolate the process control angle and can lead to quicker diagnosis of platform-specific behaviors, as well as show potential for future process abstraction. For example: to check the behavior offunc-e
when we sendSIGKILL
to it (in Linux, we need to make sure the child dies and receive whatever signal we have configured inSysProcAttr.Pdeathsig
).We changed the setting for
SysProcAttr.Pdeathsig
toSIGKILL
since when anyone sendsSIGKILL
on Linux tofunc-e
, we want the spawned envoy to receiveSIGKILL
as well. Reference: #371 (comment).This also abstracts away the process for building any fake binary that optionally uses some of
func-e
internal packages. For example, in this change, we can isolate the build for fake func-e to useinternal/moreos
package (to check onmoreos.ProcessGroupAttr()
) only and no more than that what it requires.Signed-off-by: Dhi Aurrahman dio@rockybars.com